This is a comment left during a code review.
Path: apps/dashboard/src/components/vibe-coding/chat-adapters.ts
Line: 540

Comment:
**Chips consumed before stream completes**

`consumePendingChips?.()` is called before the `streamDashboardCode` loop runs. If the stream fails with a network error, the `catch` block fires and the user's widget/error chips are already cleared — they need to re-click the widget or manually re-trigger the error to rebuild them.

A simpler approach is to consume chips only after at least one successful streaming yield:

```ts
let chipsConsumed = false;
if (chips.length > 0) {
  // inject chipBlock …
  // don't consume yet
}

for await (const content of streamDashboardCode(…)) {
  if (!chipsConsumed) { consumePendingChips?.(); chipsConsumed = true; }
  latestContent = content;
  yield { content };
}
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: apps/dashboard/src/components/vibe-coding/dashboard-tool-components.tsx
Line: 25-27

Comment:
**Module-level mutable state shared across `DashboardToolUI` instances**

`setCurrentCodeRef`, `currentCodeRef`, and `listeners` are module-level singletons. If two `DashboardToolUI` instances coexist in the same React tree (e.g., side-by-side pane, or two chat panels rendered simultaneously), the second mount will overwrite `setCurrentCodeRef` and `currentCodeRef`, causing "Restore this version" in any tool card to operate on whichever dashboard last registered. The effect cleanup (`setCurrentCodeRef = null`) mitigates sequential navigation, but simultaneous instances will silently conflict.

Consider moving these into a React context or a stable per-instance ref passed down from the parent instead of module globals.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/dashboards/[dashboardId]/page-client.tsx
Line: 195-201

Comment:
**`pendingChipsRef` can be stale after `removePendingChip`**

`removePendingChip` only calls `setPendingChips(…)`. The ref is re-synced in a `useEffect`, which runs asynchronously after paint. If the user removes a chip and then immediately submits the composer before the effect flushes (e.g., keyboard shortcut), `getPendingChips()` will still return the removed chip and it will be injected into the AI request.

Update `pendingChipsRef.current` synchronously inside the state updater:
```ts
const removePendingChip = useCallback((id: string) => {
  setPendingChips((prev) => {
    const next = prev.filter((c) => c.id !== id);
    pendingChipsRef.current = next;
    return next;
  });
}, []);
```

How can I resolve this? If you propose a fix, please make it concise.